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[57] ABSTRACT 

A system and method for performing flexible workflow 
process execution in a distributed workflow management 
system is described. The distributed workflow management 
system is formed by a computer network comprising a 
plurality of computers. Each computer has a processor, 
memory and input/output facilities. A workflow process 
management system operates on one or more of the com- 
puters to control the computer network in executing the 
workflow process. The workflow process includes at least 
one sequence of multiple actions. A plurality of resources is 
coupled to respective ones of the computers to carry out the 
multiple actions. A plurality of state machines are stored as 
computer-operable code in at least one memory and include 
a plurality of states interconnected by arcs logically forming 
a directed graph. The workflow management system further 
includes logic for instantiating each action with one state 
and logic for executing the logical sequence of the action as 
state transitions in each state machine. 

7 Claims, 10 Drawing Sheets 
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SYSTEM AND METHOD FOR PERFORMING 
FLEXIBLE WORKFLOW PROCESS 
EXECUTION IN A DISTRIBUTED 
WORKFLOW MANAGEMENT SYSTEM 

CROSS-REFERENCE TO RELATED 
APPLICATION 

The present patent application is a continuation applica- 
tion of provisional application No. 60/032,567, filed Dec. 5, 
1996, by Weimin Du et.al., and entided WORKFLOW/ 
PROCESS FLOW PROCESS MANAGEMENT SYSTEM, 
the disclosure of which is incorporated herein by reference. 

This patent application is also related to a commonly- 
assigned patent application Sen No. 08/768,261, filed on 
Dec. 17, 1996, U.S. Pat. No. 5,826,239 and entided DIS- 
TRIBUTED WORKFLOW RESOURCE MANAGEMENT 
SYSTEM AND METHOD. 

BACKGROUND OF THE INVENTION 

The present invention relates to the field of workflow 
process management and more particularly to a system and 
method for performing flexible workflow process execution 
in a distributed workflow management system. 

Workflow process re-engineering, that is, the fundamental 
rethinking and re-implementation of workflow processes to 
achieve never-before-possible levels of quality, cost, 
throughput and service, is emerging as one of the crucial 
business strategies of the 1990s. The need for re-engineering 
is especially significant in an era of workforce downsizing 
coupled with greater demands for shortened time to market 
and faster customer response. Moreover, the need is perva- 
sive. Organizations are currently engaging in workflow 
process re-engineering in many domains, including financial 
services, telecommunications services, healthcare services, 
customer order fulfillment, manufacturing procedure auto- 
mation and electronic commerce. 

While workflow process re-engineering provides a busi- 
ness management concept, workflow process management 
(WFPM) software— or more accurately, middleware — 
provides the enabling technologies for actually performing 
workflow process re-engineering. WFPM supports flexible 
solutions for the management of enterprise -wide operations, 
including workflow process control, automation and moni- 
toring; resource allocation, authorization and authentication; 
task initialization and data exchange; and end-to-end com- 
munication and security. However, while WFPM offers an 
overall environment and approach to unifying, automating 
and measuring workflow processes, it is not limited to 
supporting workflow process re-engineering and can be used 
to manage existing nonautomated legacy or work processes. 

In general, WFPM systems perform a wide range of tasks. 
For instance, they can provide a method for defining and 
managing the flow of a work process or support the defini- 
tion of resources and their attributes. In addition, they can 
assign resources to work, determine which steps will be 
executed next within a work process and when they will be 
executed and can ensure that the workflow process continues 
until proper termination. Moreover, they can notify 
resources about pending work, enforce administrative 
policies, such as access control and track execution and 
support user inquiries of status. Finally, they can provide 
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history information in the form of an audit trail for com- 
pleted workflow processes and collect statistical data for 
process and resource bottleneck analysis, flow optimization 
and automatic workload balancing. 

5 Moreover, given the trend towards open systems and 
standards, a WFPM system must coexist with and take 
advantage of standards-based commercial products for net- 
work communication, legacy application invocation and 

10 system monitoring. In particular, these standards include the 
Object Management Group's Common Object Request Bro- 
ker Architecture (CORBA), the Open Software Founda- 
tion's Distributed Computing Environment (OSF DCE), 
Hewlett Packard's Open View and the International Stan- 

15 dards Organization Open Systems Interconnection (ISO 
OSI) X.400 technologies. 

Workflow process execution should be correct, efficient 
and flexible. Flexible execution of workflow processes is 

20 important in a dynamic workflow environment. For 
example, a workflow process might need to be modified 
after being started. A resource manager might not be able to 
find resources for the workflow activities and a workflow 
assigned to an activity might not be able to perform the 

25 assigned task. A WFPM system must be flexible enough to 
cope with these situations to provide correct and efficient 
workflow process execution. 

Existing workflow products adopt a centralized process 

30 execution strategy which requires all workflows to be reg- 
istered with the WFPM system before use. The relationships 
between WFPM systems and resource managers, that is, 
built-in resource managers, and between workflow activities 
and resources specified at process definition time are static. 

35 Thus, the process execution is inefficient, as some resource 
managers and workflows might be heavily loaded while 
others remain idle. The approach is also inflexible, as it is 
difficult to change resource manager and workflow at 

4Q runtime, particularly during resource assignment or appli- 
cation execution processing. 

Therefore, what is needed is a flexible and preferably 
decentralized WFPM system able to dynamically redefine 
the relationships between the WFPM system and resource 

45 managers. 

There is a further need for a flexible WFPM system 
capable of dynamically redefining workflow activity and 
resource definitions to efficiently perform process execution. 

5Q Such a WFPM system would preferably balance the distri- 
bution of such process execution between resource manag- 
ers and workflows to minimize overloading and idle time. 

There is still a further need for a flexible WFPM system 
capable of dynamically change resource assignments and 

55 application execution processing to resource managers and 
workflows at runtime. 

SUMMARY OF THE INVENTION 
The present invention provides a system and method for 
60 performing flexible workflow process execution in a distrib- 
uted workflow management system. It is an object of the 
present invention to provide process execution techniques 
for allowing flexible process instantiation, resource assign- 
65 ment and application execution. 

An embodiment of the present invention is a system and 
method for performing flexible workflow process execution 
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in a distributed workflow management system. The distrib- FIG. 11 shows the activity state machine for the activity 
uted workflow management system is formed by a computer instance manager for use with the workflow process soft- 
network comprising a plurality of computers. Each com- ware engine of FIG. 4. 

puter has a processor, memory and input/output facilities. A FIG. 12 shows the rule node instance state machine for the 

workflow process management system operates on one or 5 rule node instance manager for use with the workflow 

more of the computers to control the computer network in process software engine of FIG. 4. 

executing the workflow process. The workflow process DETAILED DESCRIPTION 

includes at least one sequence of multiple actions. A plural- Workflow Process Management System 

ity of resources is coupled to respective ones of the com- w FIG. 1 shows a block diagram of a workflow process 

puters to carry out the multiple actions. A plurality of state management (WFPM) system 10 implemented in a network 

machines are stored as computer-operable code in at least 11 of computer systems 12a-d coupled to a plurality of users 

one memory and include a plurality of states interconnected 14a-£> and machines ISa-b for management and control of 

by arcs logically forming a directed graph. The workflow workflow process activities. Each computer system \2o-d is 

management system further includes logic for instantiating 15 shown coupled with a single user 14a-b or machine 15a-b, 

each action with one state and logic for executing the logical but multiple users or machines or combinations thereof can 

sequence of the action as state transitions in each state also be employed. The WFPM system 10 is shown from an 

machine. enterprise perspective with the control and coordination of 

The foregoing and other objects, features and advantages 20 eaca °f tne computer systems 12a-d being accomplished by 

of the invention will become more readily apparent from the computer software, preferably object-oriented software, 

following detailed description of a preferred embodiment of executed as a distributed application by the computer sys- 

the invention which proceeds with reference to the accom- terns Vla-d. Optionally, workflow process activity 

panying drawings. information, such as resource data and rules, can be stored 

25 in a database on a centralized WFPM server 17 which is 
BRIEF DESCRIPTION OF THE DRAWINGS by ^ compu(er syslems ^ 

FIG. 1 is a block diagram of a process flow management n 0 r can be stored in a plurality of databases on each of the 
system implemented in a network of computers coupled to computer systems \2a-d. The computer systems \2a-d and 
a plurality of users and machines for management and 3Q centralized WFPM server 17 conventionally include a 
control of workflow process activities performed by the processor, memory and input/output interface including net- 
users and machines. work communications facilities and user input and output 

FIG. 2 is a block diagram of a hardware and software devices, 

machine for a typical node in the network of FIG. 1 showing Each workflow process 18 includes a sequence of 

the architecture of an example of process flow management 35 activities, each of which is ordinarily performed by one of 

middleware employing the present invention. the computer systems \2a-d in conjunction with an associ- 

FIG. 3 is a computer display of the user interface for the a ted user 14a-b or machine ISa-b, although some activities 

user of the machine of FIG. 2 to interact with the process can be performed by microprocessor-controlled devices 16 

flow management system, the display showing an example 40 (one such device shown in FIG. 1, although multiple devices 

of a process flow diagram for a business process flow can be used), such as a telephone or facsimile machine, 

managed by the system. printing device or similar self-controlling mechanism. In 

FIG. 4 is a block diagram of the preferred form of addition, each machine ISa-b can be a work instrument or 

workflow process software engine that coordinates execu- computer resource. 

tionflowof the managed process. 45 n * woikflow process 18 can span several business 

r • i_i 1 j* r* L * l * * *u organizations (only one organization is shown in FIG. 1) 
FIG. 5 is a block diagram of the system architecture with f . r 1 • t1 , T 
! 1 v . t. ji j , - j . u a\ c with multiple activities potentially performed in parallel. In 
optional worklist handler and application data handler fea- r t m ' , tt 
J < 1 1 u*r* such cases, the WFPM system 10 acts as the "superstruc- 
tures to enhance scalability. \ / ■ 
, r hire that ties together disparate computer systems Ma-d 
FIG. 6 is a diagram showing management function layers 50 . u;cnxj 
? n - , whose business purposes are interconnected. The WFPM 
provided by business process flow management using the * m -j j 1 * *• 11 r*u 1 
r „ J / c system 10 provides procedural automation 13 of the work- 
system of FIGS. 1-5 for the example of management of a a it) , f 
J . r & flow process 18 by managing the sequence 01 process 
telecommunications network. .. ... , . .. c • . 1y4 , 

activities and the invocation 01 appropriate user 14a-b, 

FIG. 7 is a process definition diagram for configuration 55 machine 15fl _ 6 Qr micropr0C essor-controlled device 16 

management of the telecommunications network in the resources associated with the various activity steps, 

example of FIG. 6. Workflow Process Specification 

FIG. 8 shows, by way of example, a workflow process The procedural automation 13 of the workflow process 18 
specified via the workflow process definition interface using " involves the high-level specification of individual work- 
the process design modules shown in FIG. 2. 60 fl ows (examples shown in FIG. 3 and FIG. 7) which pro- 
FIG. 9 shows the process state machine for the process vides the operational "glue" and environment support 
instance manager for use with the workflow process soft- needed by the WFPM system 10 for managing and auto- 
ware engine of FIG. 4. mating the workflow processes 18, recovering from failures 
FIG. 10 shows the work node instance state machine for 65 and enforcing consistency. As further described 
the work node instance manager for use with the workflow hereinbelow, the WFPM system 10 also enforces various 
process software engine of FIG. 4. administrative policies associated with resources and work. 
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The specific structure and flow of each workflow process to ring interface. The workflow management interface is 
18 managed by the WFPM system 10 can be preplanned or used to allocate, at run time, execution resources to a task, 
developed in an ad hoc fashion. For example, in a WFPM according to the policies defined by the organization 
system 10 used for managing the workflow process 18 of (including authorization and authentication) and the avail- 
providing telecommunications services, some aspects of the 5 ability of the resources using the workflow management 
workflow process 18 are determined ad hoc and depend in modules 28a-c. Interaction with the external world, such as 
part on the services required by each individual customer. invoking an application, controlling an instrument or deliv- 
However, other aspects of the workflow process 18 can be ering a work order to a person's electronic mail in-box, is 
preplanned and deliberately structured. For instance, inde- performed by the various business object management mod- 
pendent from the individual services required by a single 10 ules 30, 31, 32, 33. 
customer, the workflow process 18 always originates in the HP OpenPM Process Model 

sales department and typically ends in the billing depart- In general, a workflow process 18 is a description of the 

ment. The parts of the workflow process 18 involving these sequencing, timing, dependency, data, physical agent 

departments can be preplanned. 15 allocation, business rule and organization policy enforce- 

HP OpenPM ment requirements of process activities needed to enact 

FIG. 2 is a block diagram of a hardware and software work. FIG. 3 shows, by way of example, a workflow process 

machine for a typical node 12a in the network 11 of FIG. 1 18 which is represented as a directed graph 40 consisting of 

showing, by way of example, an architecture for WPFM a set of nodes connected by arcs as displayed on the HP 

middleware employing the present invention. An example of 2 o OpenPM user interface. 

middleware suitable for implementing the present invention There are two kinds of nodes: work nodes 41, 43, 45, 46, 

is the Hewlett Packard (HP) OpenPM system. HP OpenPM 48, 50, 52, 54, which are shown as squares, and rule nodes 

is an open, enterprise -capable, object-oriented WFPM sys- 42, 44, 47, 49, 51, 53, 55, which are shown as circles. There 

tern developed at Hewlett Packard Laboratories, Palo Alto, are also two kinds of arcs, forward arcs and reset arcs. A 

Calif., for managing process activities that support complex 25 work node has at most one inward arc and one or more 

enterprise processes in a distributed, heterogeneous comput- outward arcs. A rule node can have any number of inward 

ing environment. The use of a WFPM system 10 imple- and outward arcs. 

mented in middleware represents a substantial evolution Forward arcs represent the forward execution flow of 

over traditional workflow technologies. HP OpenPM pro- 3Q process activities and form a directed acyclic graph 40. 

vides a generic framework and complete set of services for Successful completion of a node at the source end of a 

workflow process management using a middleware-based forward arc triggers the starting of the node at the destination 

approach with an emphasis on performance, availability, end of the forward arc. 

scalability and system robustness. Reset arcs are used to support repetitions or explore 

Briefly, HP OpenPM provides an open system with a 35 alternatives in a workflow process 18. Reset arcs differ from 

Workflow Management Coalition-standard interface. forward arcs in that they reach backwards in the process 

Second, it offers high performance as a result of optimized graph. 

database access and commitment features. It also provides Work nodes 41, 43, 45, 46, 48, 50, 52, 54 represent 

effective management when coupled with an HP Open View- ^ activities to be performed external to the HP OpenPM 

based system management environment. Finally, HP engine 20. These activities include authorization, resource 

OpenPM presents a comprehensive solution for business allocation, execution of business objects and provision of 

re-engineering, including an extensive set of products. input data for the business objects and output data from 

The overall architecture of the HP OpenPM system is them. Rule nodes 42, 44, 47, 49, 51, 53, 55 represent 

depicted in FIG. 2. The core is the HP OpenPM engine 20, 45 processing internal to the HP OpenPM engine 20. This 

which supports five interfaces. The interfaces enable the HP processing includes decisions of about which nodes should 

OpenPM engine 20 to interact with workflow process execute next, generation or reception of events, and simple 

designer 22a-c, workflow process instance execution data manipulation. 

23a-b, workflow process monitor 24o-c, workflow man- A work node 41 is a placeholder for a process activity, 

agement 2%a-c and business object management modules which is a logical representation of a piece of work con- 

30, 31, 32, 33, In addition, worldwide web client support is tributing towards the accomplishment of a process 18. A 

provided by each individual network node 12a which can process activity is mapped to the invocation of an operation 

execute middleware modules expressed in platform- on business objects during the execution of the process and 

independent languages, such as Java Applets and HTML 55 each process activity can represent a manual operation by a 

code. An HP OpenPM database 21 is maintained on the human or a computerizable task to execute legacy applica- 

centralized WFPM server 17 (shown in FIG. 1) for use by tions 30, 31, 32, 33 (shown in FIG. 2), access application 

the HP OpenPM engine 20. databases 34a, 34b (also shown in FIG. 2), control 

A workflow process 18 is specified by the process design instrumentation, sense events in the external world or effect 

modules 22a-c via the workflow process definition inter- 60 physical changes. A process activity definition includes a 

face. An instance of a workflow process 18 can be started, forward activity and optionally, a compensation activity, a 

controlled or stopped by the process instance execution cancel activity, a workflow management activity, timeout 

modules 2$a-b via the process execution interface. Status and deadline information and input and output data, 

information of each process instance and load information 65 Rule nodes 42, 44, 47, 49, 51, 53, 55 are used to specify 

for the WFPM system 10 can be queried using the process workflow processes 18 that are more complex than a simple 

status monitor modules 24a— c via the process status moni- sequence. A rule language is used to program the rule node 
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decision. When executed, a rule node 42 determines which specific version is requested at the time a workflow process 

outward arcs to fire based on the status passed along the instance is created. 

inward arcs, the time at which each inward arc is fired and To monitor the progress of running process activities and 

process- re levant data associated with the process instance. support system management, the HP OpenPM engine 20 

Rule nodes 42, 44, 47, 49, 51, 53, 55 are also used to 5 maintains a comprehensive log of all events using a log 

support events. A rule node 42 can raise events when certain manager 70 and provides a native interface 79a as well as an 

conditions are met as defined by the rules and an event can SNMP 79b and CMIP 79c gateways to facilitate integration 

activate rule nodes that have subscribed to receive the event. with the HP OpenView environment. The formats and 

Rule nodes 42, 44, 47, 49, 51, 53, 55 are executed each contents of the logged information can be customized to 

time any inward arc fires. Work nodes 41, 43, 45, 46, 48, 50, 10 support specific application needs. 

52, 54 have states of initial or fired. When the inward arc is HP OpenPM Workflow Objects 

fired on a work node 41 in the initial state, the work node 41 The HP OpenPM engine 20 has to interact with process 

changes its state to active and performs or requests its activities supported by various implementations encoun- 

associated activity. When the inward arc is fired on a work 15 tered in real life. These activities can range from manual 

node 41 in a state other than the initial state, nothing is done. handling by users 14a-b to automated processes executed by 

A reset arc, for example, between nodes 42-45, together computers l$a-b. An infrastructure is needed to enable the 

with the forward arcs between its destination and source, effective management and invocation of these process 

forms a loop. When traversed, a reset arc causes all nodes activities. 

42-45 within its loop to be reset. Resetting a fired work node 20 Distributed object technologies have become the primary 

43 changes its state to initial so that the node 43 can be infrastructure for enterprise -scale distributed computing, 

re-executed. Resetting an active work node 43 cancels the Among them, the OMG (Object Management Group) 

current execution of the corresponding process activity and CORBA (Common Object Request Broker Architecture) 

changes its state to initial. technology has been developed to support interoperability 

Associated with each workflow process 18, there is a 25 for application integration, 

process data template defined by a workflow process Based on CORBA technology, in the HP OpenPM engine 

designer module 22a (shown in FIG. 2). The process data 20, an abstraction called a business object 93a (shown in 

template is used to provide initial data for the creation of FIG. 5) is built to encapsulate whatever piece of work each 

process instances. At run time, based on the process data 30 process activity has to accomplish. The wrapping code 

template and read/write lists of activities defined in a work- provides an IDL (Interface Definition Language) interface, 

flow process 18, HP OpenPM will generate a case packet for The business objects are catalogued by a database manager 

each process instance to facilitate data passing between 64 in the HP OpenPM business object library in business 

activities and the HP OpenPM engine 20. databases 94a-<: (shown in FIG. 5). An object cache 75 is 

HP OpenPM Process Execution 35 optionally used to optimize business object access. 

FIG. 4 is a block diagram of the preferred form of a A business object 93a, as defined by the OMG, is a 

workflow process software engine, such as the HP Open PM representation of something active in the business domain, 

engine 20, that coordinates execution flow of the workflow including its business name and definition, attributes, behav- 

processes 18. The HP OpenPM engine 20 functions as a ^ ior and constraints. It provides a uniform way to encapsulate 

highly reliable, log-based state machine which interfaces legacy systems and applications and a direct mapping, in 

with external environments through a uniform CORBA- understandable business terms, between the business model 

based transport interface, independent of the actual physical and the possibly sophisticated operational procedures of the 

dispatch of the requests. workflow process system. 

The HP OpenPM engine 20 launches workflow process 45 By representing these process activities in business 

instances in response to user requests. For each instance, the objects 93a-c, new workflow processes 18 can be quickly 

HP OpenPM engine 20 steps through the nodes in the created by assembling business objects 93a-c to describe 

directed graph 40 (examples shown in FIG. 3 and FIG. 7) workflow processes 18. The business object library avoids 

according to the order specified in its workflow process ^ repetitive coding to tailor the process activity implementa- 

definition. For work nodes, the HP OpenPM engine 20 tion to each individual workflow process 18. 

executes the associated process (forward) activity. For rule HP OpenPM Resource and Policy Management 

nodes, the HP OpenPM engine 20 evaluates the rules and A resource is a person, computer process or machine that 

performs the rule actions when the rule conditions are met. can be used to accomplish a task. A resource has a name and 

Each node transition is durably logged to facilitate for- 55 various attributes defining its characteristics, such as job 

ward rolling of incomplete workflow processes 18 at system code, skill set, organization unit and availability, 

restart time in the event of a system failure or to facilitate a Apolicy is a set of rules that determines how resources are 

support activity compensation process in the case of a related to tasks within a WFPM system 10. One common use 

process activity failure. In addition, the HP OpenPM engine is for task assignment. Policies can be used to specify which 

20 allows flexible specification of compensation scopes and 60 resource, under which role, is eligible or available to per- 

actions, such as compensation activity or cancel activity to form a task. Policies are also used to ensure proper autho- 

support various application needs. rization and authentication. 

In the HP OpenPM engine 20, different versions of similar In HP OpenPM, the mapping between the process activity 

workflow processes 18 are supported by the engine 20 under 65 (task) specified in a workflow process 18 and the business 

the concept of a process group. A user can designate a object (resource) to be invoked is performed by the resource 

particular version as the default version to be used when no manager 28a (shown in FIG. 2) during run time as part of the 
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execution of the process activity. The HP OpenPM engine 20 new management services as rapidly as possible, to monitor 

allows multiple resource managers 28a-c to be used to and measure processes, to tune processes to benefit from 

resolve a single resource assignment request; each resolves experience and to automate processes to reduce execution 

the request at a different level within an organization. time. 

HP OpenPM Worklist and Application Data Handlers 5 SONET Configuration Management Prototype 

FIG. 5 is a block diagram of the system architecture of FIG. 7 is a process definition diagram for configuration 

FIG. 2 with optional features to enhance scalability of HP management of the telecommunications network in the 

OpenPM systems. Two optional components mat can be example of FIG. 6 based on the HP OpenPM system. It 

added into the HP OpenPM engine 20 environment to depicts a prototype to demonstrate the application of WFPM 

facilitate the execution of workflow processes 18 are 10 technology in the specific domain of SONET (Synchronous 

worklist handlers 91a-c and application data handlers Optical Network) configuration management. The prototype 

92a-c. was a joint project between HP Laboratories in Bristol, 

The worklist handler 91a supports both engine-push and England and Palo Alto, Calif, to demonstrate the middleware 

client-pull modes to provide more freedom in task assign- technologies required to automate the processes supporting 

ment. In addition, the worklist handler 91a can be used to the configuration management of a SONET telecommuni- 

support the concept of integration on demand. Based on the cations network. 

task performer's profile, the worklist handler 91a determines The scenario demonstrated by this prototype consists of 

and launches a specific environment for an activity at run the provision of a new VC4/VC12 path for customers. It 

time, rather than hardwiring it into the process definitions. 20 goes through several different steps for this operation: search 

The application data handler 92a supports the separation for a new route, negotiate the service level agreement (SLA) 

of application-specific data and process-relevant data to wi tn tne customer, configure the new path, and finally, 

reduce the amount of data flow over the network. It also u P date the SLA for this customer. The HP OpenPM process 

provides the preparation facility for application-specific data definition supporting the process of providing this new 

to remove the burden of database access from activity 25 SONET data path is sketched in FIG. 7 which shows the HP 

performers. Open View process definition for SONET configuration 

HP OpenPM Security management. 

In today's business environments, security must be imple- Searching for and configuring a new path in SONET are 

mented enterprise-wide. The security service developed by 30 complex processes requiring a lot of interaction with the 

the OMG provides authentication and encryption for the HP SONET MIB (Management Information Base) and network 

OpenPM engine 20 to prevent eavesdropping and forgery. elements. This type of operation is a source of errors when 

The HP OpenPM engine 20 infrastructure components can it is performed manually by an operator as a set of 

identify each other and vouch for the credentials of end-user individual, uncorrelated activities. 

components. 35 In the prototype, such complex operations as searching 

WFPM in the Telecommunications Management Network and configuring new paths are handled as workflow pro- 

FIG. 6 is a diagram showing management function layers cesses 18 and automated by an HP OpenPM engine 20 in an 

101, 102, 103, 104, 105 provided by workflow process environment interacting with HP OpenView DM and Oracle 

management using the system of FIGS. 1-5 for an example 4Q DBMS applications. 

of the management of a telecommunications network. The Depending upon the changing business needs, a customer 

Telecommunications Management Network (TMN) defined can request to add or drop communication paths between 

by the International Telecommunications Union is changing certain endpoints in a private virtual network (PVN). In HP 

the way operations support systems and business support OpenPM, these services can be modeled as workflow pro- 

systems solutions are being developed. The TMN architec- 45 cesses 18 to be executed by the service provider. Adding a 

ture separates layers of functionality and provides access by new path may consist of the following activities and deci- 

elements in any one layer to any element in the layer sion points: 

immediately below, as shown in FIG. 6. Before the intro- 1. Retrieve the customer's profile from the customer 

duction of the TMN model, operations support systems and database for customer-PVN-specific information, 

business support systems solutions were isolated from each 2. Locate the closest add -drop multiplexers (ADMs) to 

other and could not intemperate. the endpoints, based on the information stored in the 

The HP OpenView Distributed Management platform SONET physical configuration database, 

supports the realization of TMN operations support systems 3. Check whether fiber connections exist between the 

and business support systems solutions for the TMN element 55 endpoints and the two end -ADMs. 

management layer 104 and network management layer 103. 4. If not, issue a request for an engineer to go on-site and 

However, a middleware service is needed for supporting the physically connect the endpoints to the end- ADMs. After the 

service management layer 102 and even the business man- establishment of the connection, the process continues on to 

agement layer 101 of the TMN model. The next section step 5 and an independent subprocess is initiated to watch 

presents an example of this support. 60 for resource changes. 

At the service management layer 102, the WFPM process 5. Find valid routes between end-ADMs. This requires 

enabling framework is required to be able to support access to the routing table in the SLA database to determine 

re-engineering and transformation processes for strategic whether any valid routes exist between the two end-ADMs. 

operations support systems and business support systems, to 65 Either a fist of ADMs is returned signifying the ADMs that 

integrate existing operational environments to form an enter- must be configured to realize the route, or "No Route 

prise hub for service management and provisioning, deploy Found" is returned. For a returned list of ADMs, this activity 
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will then use the HP Open View DM facility agent to collect and reset arcs. Forward arcs represent the normal execution 

port information stored in the MIB to determine the avail- flow of a workflow process through the directed graph 140. 

able ports between the ADMs that are fibered together and Normally, the workflow moves from a source node 146 upon 

can be used to enable the path. the completion of its assigned tasks over one or more 

6. Check network element (NE) capabilities. For an ADM 5 forward arcs to destination nodes 147, 149 to initiate their 
in the route, this activity uses the HP OpenView DM NE assigned tasks. By contrast, reset arcs explore alternatives in 
agent to access the MIB information to determine whether a a workflow process by creating cycles in the directed graph 
VC4 cross-connection can be set up in the ADM between the 140. Thus, the source node of a reset arc, unlike a forward 
selected ports of the ADM. This activity has to be executed arc, must ultimately be reachable from the reset arc's 
for each ADM in the route. During steps 5 and 6, if any 10 destination node. For example, work node 150 is connected 
additional resources become available, HP OpenPM cancels by a reset arc to work node 141 and is reachable along the 
any currently running activity and starts the process over path consisting of the forward arcs connecting work node 
from step 5 to consider these newly available resources. 141, rule node 142, work node 145, work node 149 and work 

7. Get customer's approval of the selected configuration. 15 node 150. At runtime, when the reset arc is traversed, all 
Once a suitable path is identified, the customer will review nodes 141, 142, 145, 146, 149, 150 falling within the loop 
the offer, including available date, charges, quality of ser- are . "reset." A reset changes their respective states to an 
vices (QoS), and so on. Depending upon the business factors initial state for re-execution and allows the workflow pro- 
(e.g., cheapest service wanted), the customer may request cess to try different alternatives or repeat what has already 
that a new search be initiated, that is, loop back to step 5 to 20 been done. 

find another valid route. The foregoing workflow process definition enables an 

8. Configure the selected route. This activity is respon- instance of a workflow process to be flexibly controlled via 
sible for setting up the cross-connections in each ADM by the process execution interface using the process instance 
invoking the HP OpenView DM NE agent and updating the execution modules 23a-b (shown in FIG. 2). Moreover, 
SLA database. 25 status information for each process instance and load infor- 
Flexible Workflow Process Execution mation for the entire system can also be queried via the 

FIG. 8 shows, by way of example, a workflow process process status monitoring interface using the process status 

specified via the workflow process definition interface using monitor modules (shown in FIG. 2). 

the process design modules 22a-c shown in FIG. 2. The 3Q Workflow Process Execution State Machines 

process definition is specified as a directed graph 140 The process instance manager (PIM) and node instance 

comprising a set of nodes connected by arcs. Each node is manager (NIM) are the two key modules of the OpenPM 

labeled with timestamps indicating relative start and engine 20 (shown in FIG. 5). The PIM handles workflow 

completion times. For example, node 141 has a start time of process instance creation and termination which both require 

TO and a completion time of Tl. A question mark indicates 35 access to the HP OpenPM database 21. The NIM handles 

the node is still active with an unknown completion time. other operations, such as changing an instance state and 

For example, node 148 has a start time of HO but has not suspending and resuming instance execution. In addition, 

yet completed. the NIM is subdivided into a work node instance manager 

There are two kinds of nodes: work nodes 141, 142, 144, 4Q (WNIM) and a rule node instance manager (RNIM) modules 

145, 147-150 and rule nodes 142, 146. Each work node 141 for respectively managing work and rule nodes. The WNIM 

is a placeholder for a process activity which logically executes the associated process activity which may in turn 

represents a unit of work contributing toward the accom- invoke external business objects 93a-c. Also, an activity 

plishment of the overall workflow process. Work nodes 141 instance manager (AIM) is used to manage activity execu- 

also contain position specific information, such as a name 45 tion for the WNIM. The RNIM evaluates each rule nodes' s 

and compensation label. As further described below with rule specifications using an internal rule engine to perform 

reference to FIG. 10, the compensation label indicates that routing or event actions. 

the current work node 141 represents a possible consistent The OpenPM engine 20 functions as a set of efficient and 

execution state and can be used by other work nodes 145 as reliable state machines. There is one state machine for each 

an end compensation point to which the failed process process/work node/rule node/activity instance. Process 

execution can be rolled back. instance state machines are started and managed by the PIM. 

Each rule node 142 specifies a process flow which typi- Work node instance state machines are started and managed 

cally goes beyond a simple sequence of steps and involves by the NIM. Rule node instance state machines are started 

logic and decision points. A rule language is used to define 55 and managed by the RNIM. Activity instance state machines 

rule node 142 decisions. When invoked during runtime, the are started and managed by the AIM. State machines interact 

rule node 142 decides which outgoing arcs to fire based upon with the other state machines and OpenPM clients via 

the status information passed along incoming arcs, the time messages. Priority queues which are managed by the queue 

at which each incoming arc was fired and process-relevant manager 67 (shown in FIG. 4) are used to facilitate message 

data associated with the process instance. Each rule node 60 dispatching between the modules. 

142 can also initiate an event (not shown) when certain Each state machine is described as a connected graph, as 

conditions, as defined in by the rules, are met. Conversely, shown in FIG. 9 et seq., which consists of a set of states and 

an event can activate a rule node 142 that has subscribed to a set of state transitions interconnecting pairs of states. Each 

the event. 65 state has zero or more incoming transitions. Each state also 

All arcs are directed and start at a source node and end at has zero or more outgoing transitions. Each state transition 

a destination node. There are two kinds of arcs: forward arcs is labeled with a request. 
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The flow control of each state machine always begins in 
a state designated as the initial (quescent for AIM) state. 
Thereafter, each time the state machine enters a new state, it 
performs some action, such as queuing a request for other 
state machines or OpenPM clients. Also, at each subsequent 5 
state, the state machine checks the priority queue for 
requests. If a request is pending, the state machine dequeues 
the first request and checks the request against its state 
machine definition to determine whether there is an outgoing 
transition from the state labeled with the dequeued request. 10 
If such an outgoing transition is found, the state machine 
transitions to the next state following the outgoing transition 
with a label matching the dequeued request. Otherwise, the 
state machine ignores the request and remains in the current 15 
state. 

The subsequent sections describe the state machines for 
the PIM, WNIM, RNIM and AIM, respectively. 
Process Instance State Machine 

FIG. 9 shows the process state machine 159 for the PIM 2 o 
for use with the workflow process software engine of FIG. 
4. The process state machine 159 has six states, divided into 
four regular execution states: Initial 160, Active 163, Com- 
pleted 178 and Compensation 171; and two suspended 
execution states: Suspended Active 168 and Suspended 25 
Compensation 175. The states are interconnected with 
directed arcs, each arc labeled with the message passed from 
the source state to the destination state. 

A process instance is initially created in the Initial state 3Q 
160 and via a Create Frozen Instance arc 162 becomes a 
suspended instance in the Suspended Active state 168 or via 
a Create Instance arc becomes an active instance in the 
Active state 163. The process instance thereafter becomes 
via a Resume arc 169 an active instance in the Active state 35 
163 once the PIM activates its start nodes 141 by traversing 
their inward arcs. During execution, a process instance in the 
Active state 163 or Compensation state 171 can become 
suspended by respectively entering the Suspended Active ^ Q 
168 via a Suspend arc 165 or the Suspended Compensation 
175 state via a Suspend arc 174. While suspended, a process 
instance in the Suspended Active state 168 or the Suspended 
Compensation state 175 can be resumed by respectively 
entering the Active state 163 via a Resume arc 169 or the 45 
Compensation state 171 via a Resume arc 176. A process 
instance in the Active state 163 can be compensated by 
entering the Compensation state 171 via a Start Compensa- 
tion arc 164. Similarly, a process instance in the Compen- 
sation state 171 can resume active execution by entering the 
Active state 163 via a Compensation Complete arc 172. The 
execution of a process instance is complete if: (1) all work 
nodes are either in Initial 180 (shown in FIG. 10) (never 
activated) or Completed 203 (shown in FIG. 10) states; or 55 
(2) the process instance has been explicitly terminated, such 
as by the user. A completed process instance in the Active 
state 163 can enter the Completed state 178 via a Complete 
arc 167. A process instance can be terminated from any state, 
except the Initial state 160, by entering the Completed state 60 
178 via a Terminate arc 166, 170, 173, 177. 

To create a new process instance, a user needs to provide: 
(1) the ID of the process; and (2) initial data needed for 
process routing. In the described embodiment, this data is 65 
referred to as process relevant data in keeping with the 
definition provided by the Workflow Management Coalition. 
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There are also application-specific data items used by exter- 
nal applications which are not visible to the OpenPM engine 
20. A data structure (not shown), known as a case packet, 
stores the process relevant data. 

To create a process instance, the PIM performs the 
following steps: 

(1) gets the process definition, including the process data 
template, from the OpenPM database 21 (shown in 
FIG. 2) using the provided process ID; 

(2) allocates a new process instance ID and logs it into the 
system log file; 

(3) fills in the process data template with the provided 
process relevant data user has provided and writes the 
template into the database 21 as the initial case packet; 

(4) updates the process instance table (not shown) to 
reflect the new instance in the Suspended Active state 
168; 

(5) creates node and arc instances of the process; 

(6) sends a message to the NIM to change the process 
instance to the Active state 163 and return the instance 
ID to the client; and 

(7) sends messages to the NIM to traverse the inward arcs 
for each of the start nodes of the process instance. 

In step (5), creating node and arc process instances can be 
performed at three levels of detail, referred to as immediate, 
lazy and hybrid instantiation. At the most detailed level, 
immediate instantiation exhaustively creates all specified 
process node and arc instances when the process instance is 
created. This approach is easy to implement and facilitates 
the runtime modification of the process instances without 
having to change the original process definition. However, 
immediate instantiation can create node and arc instances 
that are never activated. 

At the least detailed level, lazy instantiation creates each 
process node and arc instance only when it is actually 
needed during the execution of the process instance. This 
approach avoids creating node and arc instances that are 
never executed and reduces database overhead. However, 
lazy instantiation makes ad hoc process instance modifica- 
tions at runtime difficult because all of the nodes and arcs 
have not been instantiated. 

At an intermediate level of detail, hybrid instantiation 
begins by creating only necessary node and arc instances. 
However, if the process instance needs to be changed, all 
node and arc instances that have not yet been instantiated 
and are reachable from currently activated nodes which have 
started but not yet completed are created. This approach not 
only supports ad hoc process instance modification, but also 
delays the instantiation of nodes and arcs until the process 
instance is being modified. Hybrid instantiation also avoids 
unnecessarily creating nodes and arcs that are not reachable 
from the currently activated nodes. 

A process instance automatically completes when all 
work nodes are either in the Initial 180 (shown in FIG. 10) 
or Completed 203 (shown in FIG. 10) states or can be either 
manually terminated by a user. When a process instance 
automatically completes execution, the PIM simply changes 
its state to the Completed 178 state. To terminate a process 
instance manually, a user provides the process instance ID to 
the PIM. In response, the PIM performs the following steps: 

(1) Cancels and terminates all activated but not completed 
work nodes of the process instance; and 
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(2) Changes the instance state to the Completed 178 state 
by sending a message to the N1M. 

Whenever the execution of a process instance fails at one 
of its work nodes, due to, for example, a timeout or 
execution failure, the process instance must be compensated. 5 
In response, the PIM performs the following steps: 

(1) saves all currently active work nodes 141; and 

(2) sends a message and relevant information to the 
compensation manager. iq 

The compensation manager replies to the PIM when it 
finishes compensation and the PIM will then resume the 
execution of the process instance from all active nodes not 
inside the compensation scope and the specified end com- 
pensation point. 35 
Work Node Instance State Machine 

FIG. 10 shows the work node instance state machine 179 
for the WNIM for use with the workflow process software 
engine of FIG. 4. The work node instance state machine 179 2Q 
has seven states, divided into four regular execution states: 
Initial 180, Active 183, Completed 203 and Compensation 
198; and three suspended execution states: Suspended Initial 
188, Suspended Active 190 and Suspended Compensation 
194. The states are interconnected with directed arcs, each 25 
arc labeled with the message passed from the source state to 
the destination state. 

In OpenPM, a process activity is represented as a generic 
activity. By definition, an activity is a logical unit of work 
that contributes towards the accomplishment of a workflow 
process. An activity can represent normal execution (process 
activity), a rollback operation (compensation activity) or 
termination (cancel activity). In the described embodiment, 
the activity definition is separated from its usage and all 35 
activities are defined in exactly the same way whereby each 
activity contains the following specifications: 

(a) a resource specification; 

(b) a compensation activity (can be NULL); 4Q 

(c) a cancel activity (can also be NULL); 

(d) a timeout specification, such as a time interval, or 
cancellation or compensation indicator; and 

(e) a fail handling specification for specifying whether 
compensation should occur. 45 

An activity can be reused at different work nodes 141, 
143. At runtime, the OpenPM engine 20 maps a resource 
specification to a physical business object 93o-c (shown in 
FIG. 5). Each business object 93a-c can be either an 
automated application, a manual process or an OpenPM 
subprocess. 

The work node instance state machine 179 starts from an 
Initial 180 state. A work node 141 ends in a Completed state 
203 if it either completes execution from an Active state 183 55 
via a Complete arc 186 or is terminated from the Active state 
183, a Suspended Active state 190, a Compensation state 
198 or Suspended Compensation state 194 via a Terminate 
arc 187, 193, 202 or 196, respectively. A work node 141 hi 
the Initial state 180 can enter the Active state 183 or a 60 
Suspended Initial state 188 via a Traverse Inward Arc 181 or 
a Suspend arc 182, respectively. A work node 141 in the 
Suspended Initial state 188 can enter the Initial state 180 via 
a Resume arc 189. A work node 141 in the Active state 183 65 
can enter the Suspended Active state 190 via a Suspend arc 
185. A work node 141 in the Suspended Active state 190 can 
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resume execution by returning to the Active state 183 via a 
Resume arc 191. A completed work node 141 in the Com- 
pleted state 203 can be compensated by the compensation 
manager by entering the Compensation state 198 via a 
Compensate Node arc 204. A work node 141 in the Com- 
pensation state 198 can enter the Initial state 180 via a 
Complete arc 199. A work node 141 in the Compensation 
state 198 can enter the Suspended Compensation state 194 
via a Suspend arc 200. Likewise, a work node 141 in the 
Suspended Compensation state 194 can enter the Compen- 
sation state 198 via a Resume arc 197. Finally, an active 
work node 141 can be terminated once it has started 
execution, so long as it is not in the Initial 180 or Suspended 
Initial 188 states. An active work node 141 can also be 
terminated before it completes, so long as it is not in the 
Completed 203 state. A work node 141 is ready to run if it 
is in the Initial 180 state and can be reset to the Initial 180 
or Suspended Initial 188 states from any other states by 
Reset arcs 184, 192, 195, 201 or 205. 

In the OpenPM engine 20, each work node instance 141 
has its own work node instance state machine 179 which is 
started when the inward arc from the Initial 180 state has 
been traversed. Once started, the work node instance state 
machine 179 moves into the Active 183 state and starts the 
activity instance state machine for the associated process 
activity, as further described below with reference to FIG. 
11. Each work node instance state machine 179 can only be 
started from the Initial 180 state. After being completed, the 
work node instance state machine 179 will ignore all arcs 
except reset and compensation. 

The work node instance state machine 179 moves to the 
Completed 203 state whenever it is in the Active 183 state 
and the associated activity instance state machine 209 
(shown below in FIG. 11) has completed. The work node 
instance state machine 179 also moves to the Completed 203 
state whenever it is not in the Initial 180 or Suspended Initial 
188 states and has been requested by a user to terminate its 
execution. Responsive to the user termination request, the 
work node instance state machine 179 starts an activity 
instance state machine for a cancel activity for the associated 
process activity if the work node 141 is in the Active 183 or 
Suspended Active 190 states and a cancel activity has been 
defined for the active process activity. Alternatively, the 
work node instance state machine 179 starts an activity 
instance state machine for the cancel activity if the work 
node 141 is in the Compensation 198 or Suspended Com- 
pensation 194 states and a cancel activity has been defined 
for the compensation activity. 

The work node instance state machine 179 moves to the 
Compensation 198 state only if it is in the Completed 203 
state and has been requested by the PIM to compensate the 
associated work node 141. This situation occurs when 
another work node 143 has failed and the current work node 
141 is in its compensation scope. When entering the Com- 
pensation 198 state, the work node instance state machine 
179 starts an activity instance state machine for the com- 
pensation activity of the associated process activity. 
Activity Instance State Machine 

FIG. 11 shows the activity state machine 209 for the AIM 
for use with the workflow process software engine of FIG. 
4. The activity state machine 209 has four execution states: 
Start Business Object (Start BO) 210, Quiescent 214, Get 
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Resource Mapping (Get RM) 216 and Get Business Object machine 214 sends a message to traverse the outward arc of 

(Get BO) 219. The states are interconnected with directed the containing work node 143 so the activity state machine 

arcs, each arc labeled with the message passed from the 209 for the next work node 144 can get started. However, if 

source state to the destination state. As described above with me activity is a compensation activity or a cancel activity for 

reference to FIG. 9, the major responsibility of a work node 5 a compensation activity, the activity state machine 179 sends 

instance state machine 179 is starting state machines for a message to the compensation manager (not shown) to 

associated process, compensation and cancel activities. mform il of me completion of the node compensation. 

Since all activities, including resource activities, have the if activit y 15 a resource ma PP ia S actiYitv > the 

same specification, the OpenPM engine 20 employs a 10 activit y state m ™*™ J 79 sends a ****** to ^ctivity 

generic activity state machine to execute all activities with state machine 179 of the containing activity regarding the 

* j. * j , , f . , physical business objects 93a-c so that it can proceed with 

a dedicated state machine for each particular activity. iL L • * , 

„ ... c L w- • i i execution. After these actions have been performed, the 

TTiere are three types of paths. Minimal normal activity sUte m moves back t0 lhe 

execution i paths start from the Quiescent state 214 go Qukscen{ state 214 imJicati me successful completion of 

through the Get RM state 216 via a Start Activity arc 215, 35 ±c activity cxecution 

the Get BO state 219 via a Get RM OK arc 218 and the Start Fai l Action and Timeout Action perform actions specified 

BO 210 state via a Get BO OK arc 222, and return back to m the mvo king activity's timeout and failure handling 

the Quiescent state 214 via a BO Completed arc 211. The specifications, respectively. These actions include, for 

activity state machine 209 always returns along failure paths 20 example, canceling the activity execution, compensating the 

to the Quiescent state 214 via a BO Failed arc 212, Get BO process execution and so forth. Messages are sent to the 

Failed arc 221 or Get RM Failed arc 217 when failed and can work node instance state machine 179 (or the process 

fail at any of the states except the Quiescent state 214. The instance state machine 159) to start a cancel activity state 

Redirect RM arc 220 is an optional execution path. machine or compensation process. The activity state 

The activity state machine 209 also supports redirect 25 machine 179 also moves back to the Quiescent state 214, 

resource mapping in the Get RM 216 state and can delegate indicating unsuccessful completion of the activity execution, 

applications in the Get BO 219 state via a Delegate BO arc Resource Mapping 

213. Redirect resource mapping is needed when the selected Each activity has a resource specification consisting of 

resource manager (not shown) recommends back to the 3Q two major parts: a role specification and a mapping speci- 

OpenPM engine 20 that another resource manager is better fication. The role specification is a logical specification of 

suited for executing the job. The activity state machine 209 the task performer specified by activity, such as programmer, 

remains in the Get BO 219 state and contacts the new accountant, ATM and so forth. The mapping specification 

resource manager. Similarly, a business object 95a-c might can be one of the following: (1) a NULL value; (2) a specific 

suggest to the OpenPM engine 20 that another business 35 resource manager; or (3) a resource mapping activity. A 

object 93c-c is better suited for executing the job. The resource manager is a specialized OpenPM business object 

activity state machine 209, after receiving the business 93a that takes as input a role specification and an activity 

object delegation request from the business object 93a-c, name, consults an organization directory containing 

contacts the resource manager for the new business object ^ resource information, business rules and policies, selects one 

93a~c. or more capable business objects 93b-c and returns the 

During normal activity execution, the activity state selected business objects 936-c to the OpenPM engine 20. 

machine 209 starts in the Quiescent state 214 and moves to The system default resource manager is used when the 

the Get RM state 216 once started. The activity state mapping specification is NULL. A process designer 22a-c 

machine 209 dispatches a resource manager (not shown) for 45 (shown in FIG. 2) can also use a specific resource manager, 

the activity requested. The resource manager specification The purpose of the resource mapping activity is to choose 

could be another activity. The state machine next moves to the right resource manager for the role specification. The 

the Get BO state 219 if a valid resource manager has been mapping allows a hierarchical resource specification. The 

found. The activity state machine 209 contacts the resource resource managers are organized in a hierarchical fashion 

manager for business objects 93a-c that perform the activity. such that each resource manager works within the scope of 

The state machine then moves to the Start BO state 210 to the resource managers immediately below it in the hierarchy, 

invoke the selected business object 93a-c. At this state, the During process definition, the process designer 22a-c only 

OpenPM engine 20 can determine as the result of resource need know the topmost level resource manager in the 

mapping which business objects 93a-c are capable of per- 55 hierarchy. Thus, the resource mapping activities automati- 

forming the requested job and how they can be invoked. The cally find the right resource manager and map the role 

activity state machine 179 finally returns to the Quiescent specification into physical business objects 93a~c. 

state 214 until the business object 93a-c completes, either For example, assume two resource managers with one for 

successfully or unsuccessfully. technical staff and another for management staff. A resource 

In the Quiescent state 214, the activity state machine 214 60 mapping activity can be implemented such that the resource 

performs a Post Action if the business object 93a-c com- manager knows which of the other resource managers 

pleted successfully, a Fail Action if the previous execution understand a specific type of role specification. Suppose the 

failed or a Timeout Action if the previous execution timed role specification of an process activity requires the services 

out. A Post Action performs different functions based on the 65 of a programmer and the mapping specification is the above 

type of business object 93a~c. For example, if the activity is defined activity. At runtime, when the activity is invoked 

a cancel activity for a process activity, the activity state with the role specification, it returns to the activity state 
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machine 209 containing the activity in question the resource Rule Node Instance State Machine 

manager that manages the technical staff which will then FIG. 12 shows the rule node instance state machine 229 

check the technical staff directory to select a capable pro- for the RNIM for use with the workflow process software 

grammer that is available to perform the process activity. engine of. FIG. 4. Hie rule node instance state machine 209 

Redirected Resource Mapping 5 has three execution states: Initial 2 30, Active 232 and 

The purpose of resource mapping is to map a logical Suspended 236. The states are interconnected with directed 

specification of each resource to a specific resource, such as arcs> each arc labded ^ lfae m c d frQm ^ 

a user 14 a, machine 15a or microprocessor-controlied &ource ^ tQ me destination state Each ^ node U2 

device 16 (each shown in FIG. 1). Although the process of , . • ox . , /r , , 

c . .„ y . . r , m (shown in FIG. 8) has one or more inward (forward and 

perrormmg specific resource mapping might need additional 1 A , , c , , x 

• p *■ u 4- i *i_ u r rese 0 arcs > or more outward (forward and reset) arcs 

information, such as a meeting time or place, the number of , , . .„ 

people expected to attend and so forth, two pieces of and one or more rule specifications. A rule can be specified 

information are common to all resource mapping functions: baSed 0D the ™ n tune "ft*™*™. suc ° ™ timing and 

a task name and a resource role. The task name specifies the status of each mward arc > me ^ of each inward arc 

task to perform, such as scheduling a meeting. The resource 15 ( forward or reset) or the process-relevant data associated 

role defines a logical specification of the resource capable of ^ me P rocess instance. 

performing the task, such as administrative assistance. Arule node 142 fe slarted whenever one of its inward arcs 

Resource mapping is performed by a resource manager has been Seised. Rules defined in the rule node 142 will 

28a (shown in FIG. 5). The OpenPM engine 20 sends to the 20 then be evaluated b y the OpenPM engine 20. Rules in the 

resource manager 28a a message requesting a mapping, rale node 142 are aLso evaluated when one of the events to 

including a task name, resource role and other pertinent which il subscribes oc curs. Generally, a rule, if evaluated to. 

' information. If the resource manager 28a can understand the be TOUE ' does one of the following: 

task name, resource role and other information, the resource ( a ) Fires one or more of its outward arcs; 

manager 28a performs the requested mapping and replies to 25 ( b ) Changes the rule node instance status; 

the OpenPM engine 20 with a specific resource. (c) Changes data in the Case Packet; 

The resource manager 28a might not possibly understand ( d ) Subscribes to or unsubscribes from events; or 

all of the mapping requests. For example, a resource man- ( e ) Raises events. 

ager 28a for engineers might not understand a task named 30 Arule node 142 either can be for routing (route node) or 

"schedule meeting" or a resource role of "Administrative event processing (event node). Route nodes do not subscribe 

Assistance." When this happens, the OpenPM engine 20 and raise evenls whereas event nodes do. 

allows the resource manager 28a to do two things: ^ ^ node inst ance state machine 229 of each rule 

(1) Reply back to the OpenPM engine 20 with a "do not node 142 starts from the Initial state 230 and moves 10 an 
understand" message; or 35 Active state 232 via a Transverse Inward Arc 231. The rule 

(2) Reply back to the OpenPM engine 20 with a "try nodc instance state machine 229 remains in the Active state 
resource manager B" message. 232 even after its outward arcs have been fired. In the Active 

The first form of reply simply rejects the requested state 232, a rule node 142 reacts to the events to which it has 

mapping. The second form of reply informs the OpenPM 40 subscribed via a Process Event arc 233. The rule node 142 

engine 20 that the requested resource manager 28a does not can move to the Suspended state 236 via a Suspend arc 234 

know how to perform the requested mapping and suggests either explicitly in response to a user request or implicitly 

an alternate resource manager 28b. In response, the OpenPM when the process instance is suspended. In the Suspended 

engine 20 can either choose the suggested alternate resource state 236, the rule node 142 can move to the Active state 232 

manager 28b or try another resource manager 28c. 45 via a Resume arc 237. The rule node 142 can be terminated 

Application Delegation via a Terminate arc 235, 238 by being unsubscribed from all 

At run time, a resource manager can also map a role previously subscribed events. Reset arcs have no effect rule 

specification and an activity name onto a physical business nodes 142. 

object 93a-c not capable of or not available to perform the To summarize, workflow processes involve the coordi- 
job. The OpenPM engine 20 allows the business object nated execution of activities performed by workflows, such 
93a-c to reject the task and suggest a different (logical) role as a user 14a-b, a machine, instrument \Sa-b or micropro- 
or (physical) business object 93a-c. cessor controlled device 16 (all shown in FIG. 1). Each 
In the previous example, suppose the resource manager workflow process is executed by one or several coordinated 
mapped the role specification (programmer) and the activity 55 WFPM systems \2a-~d which step through the process 
to a business object 93a named Bob. If Bob is too busy, he definition and invoke workflows to perform the process 
may suggest the services of another programmer named activities. Workflow management subsystems (resource 
Mary. If she is not capable of doing the job, Bob can even managers) in the WFPM systems assign resources to work- 
suggest to the OpenPM engine 20 a new role, such as flow activities when needed. A workflow process is collec- 
designer. If the current business object 93a suggests another 60 tively run by four log-based and efficient state machines: a 
business object 936 of the same role, the activity state process instance state machine 179; rule node instance state 
machine 209 will not leave the current Start BO state 210, machine 179; work node instance state machine 229; and 
but will instead simply invoke or delegate the application to activity instance state machine 209. 

the new business object 93b. If a new role is suggested, the 65 Flexibility is achieved in several ways. First, the process 

activity state machine will move back to the Get BO state instance state machine 179 supports three different forms of 

219 to map it to physical business objects 93a-c. process instantiation: immediate instantiation; lazy instan- 
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tiation; and hybrid instantiation. Different instantiation 
approaches can be used for efficient process execution, 
runtime process modification or both. Second, the activity 
instance state machine 209 allows flexible resource 
assignment, such as multilevel, hierarchical resource assign- 5 
ment via resource activities and resource manager redirec- 
tion. Third, the activity instance state machine 209 also 
allows flexible application execution by supporting applica- 
tion delegation. A workflow not capable of performing an jo 
assigned activity can delegate the work to other more 
capable resources, thereby avoiding unnecessary failures 
and excess execution overhead for recover and compensa- 
tion. 

Having described and illustrated the principles of the 15 
invention in a preferred embodiment thereof, it should be 
apparent that the invention can be modified in arrangement 
and detail without departing from such principles. We claim 
all modifications and variations coming within the spirit and 
scope of the following claims. 

What is claimed is: 

1. A system for performing flexible workflow process in 
a distributed workflow management system that includes 
multiple computers, comprising: 

a workflow process management system operating on at 
least one of the computers to control execution of the 
workflow process which includes process instances; 

a plurality of resources coupled to respective ones of the 
computers to carry out the process instances; 

a plurality of state machines that comprise 

a process instance state machine that includes a plu- 
rality of states including (1) a compensation state 
that allows a failed process instance at a work node 35 
to be compensated such that resumption of execution 
of the failed process instance can be from a specified 
end compensation point, and (2) a suspended com- 
pensation state that allows the process instance in the 
compensation state to move to the suspended com- 40 
pensation state when the process instance becomes 
suspended; 

a work node instance state machine for a work node 
instance manager that manages work nodes of the 
workflow process, wherein the work node instance 45 
state machine includes a plurality of states including 
the compensation state and the suspended compen- 
sation state; and 

a rule node instance state machine for a rule node 
instance manager that manages rule nodes of the 59 
workflow process. 

2. A system according to claim 1, wherein the work node 
instance state machine, further comprises: 

an initial state logically coupled to an active state via a 
traverse inward arc and to a suspended initial state via 55 
a suspend arc; 

the suspended initial state logically coupled to the initial 
state via a resume arc; 

the active state logically coupled to a completed state via 6Q 
a complete arc and a terminate arc, and to the sus- 
pended active state via a suspend arc; 

the suspended active state logically coupled to the active 
state via a resume arc and to the completed state via a 
terminate arc; 



the completed state logically coupled to the compensation 

state via a compensate node arc; 
the compensation state logically coupled to the completed 

state via a terminate arc, to a suspended compensation 

state via a suspend node and to the initial state via a 

complete arc; and 

the suspended compensation state logically coupled to the 
compensation state via a resume state to the completed 
state via a terminate arc. 

3. A system according to claim 2, further comprising: 

the active state logically coupled to the initial state via a 
reset arc; 

the suspended active state logically coupled to the sus- 
pended initial state via a reset arc; 

the suspended compensation state logically coupled to the 
suspended initial state via a reset arc; 

the completed state logically coupled to the initial state 
via a reset arc; and 

the compensation state logically coupled to the initial 
state via a reset arc. 

4. A system according to claim 1, wherein at least one of 
the state machines comprises an activity instance state 
machine, comprising: 

a start business object (BO) state logically coupled to a 
quiescent state via a BO failed arc and a BO completed 
arc and to a get resource manager (RM) state via a 
delegate BO arc; 

the quiescent state logically coupled to the get RM state 
via a start activity arc; 

the get RM state logically coupled to the quiescent state 
via a get RM failed arc and to a get BO state via a get 
RM okay arc; and 

the get business object state logically coupled to the 
quiescent state via a get BO failed arc, to the start BO 
state via a get BO okay arc and to itself via a redirect 
RM arc. 

5. A system according to claim 1, wherein the rule node 
instance state machine, further comprises: 

an initial state logically coupled to an active state via a 

traverse inward arc; 
the active state logically coupled to the initial state via a 

terminate arc, to a suspended state via a suspend arc 

and to itself via a process event arc; and 
the suspended state logically coupled to the initial state 

via a terminate arc and to the active state via a resume 

arc. 

6. The system of claim 1, wherein the process instance 
state machine is started and managed by a process instance 
manager. 

7. The system of claim 6, wherein when the process 
instance state machine for the process instance is in the 
compensation state, the process instance manager 

saves all currently active work nodes of the process 
instance; 

sends a message and relevant information to a compen- 
sation manager. 
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